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(57) Abstract: The invention relates to a method for translating programmes into a system consisting of at least one first processor 
^ and a re^onfigurable unit According to the method, parts of the code that axe suitable for the re-configurable unit are determined 
and extracted and the remaining code is extracted in this manner for processing by the first proicessor. 
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(57) Zusammenfiassung: Die Erfindung betrifft ein Verfahren znr Obersetzung von Programnien auf ein System bestehend aus 
wenigstens einem ersten Prozessor und einer rekonfigorierbaren Einheit Hierbei ist vorgesehen. dass die Codeteile, die fiJr die 
rekonfigurieibare Einheit gedgiiet sind, besdnunt und extrahiert werden und der verbleibende Code zor Abarbeitung duich den 
ersten Pmzessor derart extrahiert winL 
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Titel: Verfahren zur Bearbeituhg von Daten 

Beschreibung 

Die vorliegende Erfindung befaSt sich mit Datenverarbeitung . 
Insbesondere befafit sich die vorliegende Erfindting mit her- 
k6ramlichen, d.h. konventionellen xind rekonf igurierbaren Pro- 
zessorarchitekturen sowie mit Verfahren hierfur, die eine 
Ubersetzung einer klassischen Hochsprache (PROGRAMM) wie 
Pascal, C, C++, Java, etc. ermoglichen, insbesondere auf eine 
rekonf igurierbare Architektur. Insbesondere befafit sich die 
vorliegende Erfindung mit der Integration und/oder erigen Kopp- 
lung yon rekonf igurierbaren Prozessoreii mit Standardprozesso-. 
ren, dem batenaustausch und der Synchronisation der Datenver- 
arbeitung. 

Unter einer konventionellen Prozessorarchitektur (PROZESSOR) 
werden vorliegend beispielsweise sequent ielle" Prozessoren mit 
einer von-Neumann- oder Harvardarchitektur verstanden., wie 
2.B,. Kontroller, CISC-, RISC-, VLIW-, DSP-, U.S. Prozessoren 
verstanden. 



BESTAT16UN6SK0PIE 
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Unter einer rekonf igurierbaren Zielarchitektur werden vorlie- 
gend Bausteine (VPU) mit wiederholt xmd irisbesondere zur Lauf- 
zeit insbesondere unterbrechungsfrei konf igurierbarer Funktipn 
und/oder Vernetzung verstanden, insbesondere integrierte Bau- 
igteiiie mit einef MeKrzahl von ein- oder mehrdiTnensional ange- 
ordneteri ari thine tischen und/bder logisdhen und/bder analogfen 
und/oder speichernden insbesondere evtl. auch grobgranularen 
Baugruppen (PAE) , die direkt oder durch ein Bussystem mitein- 
ander verbunden sind, 

Zur Gattxmg dieser Bausteine zahlen insbesondere systoldsche 
Arrays, neuronale Netze, Mehrprpzessor Systeme, Prozessoren 
mit mehreren Rechenwerken und/oder logischen Zellen, Vemet- 
zungs- und Netzwerkbausteine wie 2.B. Crossbar-Schalter, eben- 
so wie bekannte Bausteine der Gattung FPGA, DPGA, XPUTER, 
etc.. Hingewiesen wird insbesondere in diesem Zusammenhang auf 
die folgenden Schutzrechte desselben Anmelders: P 44 16 881.0- 
53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, 
DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198.80 129.7, 
DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 
36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 
014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 196 51 075.9-53, 
DE 196 54 846.2-53, DE 196 54 593-.5-53, DE 19? p4 '728.9, • 
DE 197 07 872.2, DE 101 39 170.6, DE 199 26 538.0, 
DE 101 42 904.5, DE 101 10 530.4. Diese sind hiermit zu Offen- 
barungszwecken vollumfanglich eingegliedert . 

Das System kann insbesondere als (Standard) -Prozessor oder 
Baugruppe ausgestaltet sein und/oder in einem Halbleiter tSy- 
atem on Chip SoC) integriert sein. 

Rekonf igurierbare Bausteine (VPUs) unterschiedlicher Gattungen 
(wie z.B. PACT XPP-Technologie, Morphics, Morphosys, Chamele- 
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on) sind 2U bestehenden technischen Umgebimgen und Program- 
mierverfahren weitgehend inkompatibel. 

Programme fflr diese Bausteine sind typisch inkompatibel zu be- 
reits bestehenden Programmen von CPUs. Dadurch wird ein erheb- 
licher Entwicklungsauf wand zur Programmierung erf orderlich, 
z.B. besonders fur Bausteine der Gattungen Morphics, Morpho- 
sys. Chameleon integriert bereits einen Standardprozessor 
(ARC) auf mehr oder minder rekonf igurierbaren Bausteinen. Da- 
durch Btehen Ansatze fiir Tools zur Programmierung zur Verfu- 
gung; Allerdings ist nicht jede technische Uragebung fur den 
Einsatz von ARC-Prbzessbren geeignet; insbesdndere liegen be- 
stehende Programme, Codebibliotheken etc. oftmals fflr beliebii- 
ge unbestimmte andere CPUs vor, 

Es hat sich in internen Versuchen gezeigt, daS es bestimmte 
Verfahren und Programmablaufe gibt, die sich besser mit einer 
rekonfigurierbare Architektur abarbeiten lassen als rait einer 
konventionellen Prozessorarchitektur . Umgekehrt gibt es auch 
seiche Verfahren und Programmablaufe, die besser mit einer 
konventionellen Prozessbrarchitektur ausgefOhrt warden kdnnen. • 
Es ist dafilr wflnschenswert, urn eine jeweilige Optimierung zu 
ermoglichen/ eirie Ablauf teilung 

Bekannte Ubersetzungsverfahren fur rekonfigurierbare Architek- 
turen unterstiitzen keine Weitergabe von Codes an beliebige 
Standard- Compiler zur Generierung von Ob jekt codes fto einen 
beiiebigen PROZESSOR. Gew6hnlicherweise ist der PROZESSOR fest 
innerhalb des Compilers definier.t. 

Weiterhin existieren keine Scheduling-Mechanismen zur Rekonfi- 
guration der einzelnen generierten Konf igurationen fur VPUs. 
Insbesondere fehlen Scheduling-Mechanismen filr die Konfigura- 

3 . 



wo 02/103532 



PCT/EP02/06865 



tion unabhangiger extrahierter Teile gleichwohl wie fflr ein- 
zelne Partitionen extrahierter Teile. Entsprechende Oberset- 
zungsyerfahren nach dem Stand der Technik sind beispielsweise 
Vdef iniert durch di^ Dissertation ^Ubersetzungsmethoden fur . 
strukturprogrammierbare Rechner, Dr. Markus Weinhardt, 1997 

Zur Partitionierung von Array-CODE sind mehrere Verfahren nach 
dem Stand der Technik bekannt, z. B* Joao M. P. Cardoso, « Com- 
pilation of Java*" Algorithms onto Reconf igiirable Computing Sy- 
stems with Exploitation of Operation-Level Parallelism^/ Ph. 
D. Thesis Universidade T^cnica de Lisbba (UTL) / 2000. 

Diese Verfahren sind jedoch in keine kompletten Conrpilersyste- 
me eingebettet. Weiterhin setzen die Verfahren die vollst&ndi- 
ge Steuerxing der Rekonf iguration durch einen Hostprozessor 
voraus, was einen erheblichen Aufwand bedeutet. Die Partitio- 
nierungsstrategien sind fur FPGA-basierende Systeme ausgelegt 
\ind entsprechen daher keinem echten Prozessormodell. 

Die Aufgabe dieser Erfindung besteht darin, Neues fixr die ge- 
werbliche Anwendung bereitzustellen. 

Die Ldsiing dieser Aufgabe wird ih unabhtogigier Form be^ 
sprucht. Bevorzugte AusfiUirungen finden sich in den Unteran- 
sprflchen. 

Bin rekonfigurierbarer Prozessor tVPU) wird somit in eine 
technische Umgebung eindesigned, die. einen Standardprozessor 
(CPU) besitzt, wie beispielsweise einen DSP, RISC, CISC- 
Prozessor oder (Mikro) -Kontroller auf weist-. Das Design kann 
erf indungsgemSS derart erfolgen, dass eine einfache und lei- 
stungsfthige Anbindung besteht* Eii) sich ergebender Aspekt ist 

die einfache Programmierbarkeit des entstehenden Systems. Die 

. 4 . 
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Weiterverwendung bestehender Programme der CPU sowie die Code- 
korapatibilitat \md die einf ache Integration der VPU in die be- 
stehenden Progranime finden Berucksichtigung, 

Eine VPU (oder ohne jeweils besonders erwahnt zu warden, meh- 
rere VPUs) wird derart mit einer bevorzugten CPU (oder oline 
jeweils besonders erwahnt zu werden, mehreren CPUs) gekoppelt, 
dass sie die Stelle und Funktion eines Coprozessors (bzw. meh- 
rerer wahlweise ansprechbarer Coprozessoren) einnimmt. Die 
Punktion ermdglicht die einfache Einbindung in bestehende Pro- 
grammcodes entsprechend den bereits exist ierenden Methoden zum 
UmcfcUig mit Coprozesspren nach dem Stand der Teehhik. 

Der erf indungsgemSSe Datenaustausch zwischen CPU und VPU kann 
tnittels Speicherkopplung und/pder lO-Kopplung erfolgen. CPU 
\ind VPU kdnnen samtliche Ressourcen teilen^ in besonderen Aus- 
gestaltungen ist es auch moglich, dass CPU vmd VPU nur einen 
Teil der Ressourcen gemeinsam vervenden und andere Ressourcen 
jeweils e3q>lizit und/oder exclusive fiir eine CPU oder VPU zur 
VerfCigung stehen. 

Um einen Datenaustausch durchzufdhren, konnen Datensatze 
xmd/odex Koiifigurationeri in jeweils biesonders dafiir yorgeseheii 
Speicherbereiche kopiert bzw. geschrieben/gelesen werden 
imd/oder entsprechende Basi^adressen gesetzt werden, dass die- 
se auf die jeweiligen Datenbereiche zeigen. 

Zur Steuerimg des Coprozessors wird bevprzugt ein Datensatz 
vorgesehen, der beispielsweise die Grundeinstellungen einer 
VPU beeinhaltet, wie beispielsweise bestimmte Basisadressen. 
Desweiteren konnen Statusvariablen zur Ansteuerung und Funkti- 
onssteuerung einer VPU durch eine CPU sowie fiir Riickmeldungen 

einer VPU an eine CPU vorgesehen sein. Der Datensatz kann flber 

... . 5 
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einen gemeinsamen Speicher (RAM) und/oder uber einen gemeinsa- 
men peripheren Adressraum (10) ausgistauscht werden. 

Zur Synchronisation der CPU und VPU kdnnen einseitig oder ge- 
genseitig wirkende Interruptverfahren (die z.B. durch Signal- 
transfer uber insbesondere dedizierte bzw; hierfur ausgebilde- 
te Interruptleitungen und/oder Interrupteingange realisiert 
sind) vorgesehen sein und/oder die Synchronisation erfolgt 
mittels Pollingverfahren. Weiterhin konnen Interrupts zur Syn- 
chonisation von Daten- txnd/oder DMA- Transfers verwendet wer- 
^den. 

In einer besonders zu bevorzugenden Ausgestaltung wird eine 
VPU durch eine CPU gestartet und arbeitet danach bevorzugt un- 
abhangig die i^plikation ab. 

Besonders leistungsf ahig ist ein bevorzugter Aufbau, bei wel- 
Chen die verwendet e VPU eigene Mechanismen zum Laden und Kon- 
trollieren von Konf igurationen vorsieht. Zur Gattung dieser 
VPUs gehdren beispielsweise PACT XPP und Chameleon. Die erf in- 
dungsgemafien Schaltungen ermoglichen eih Verf ahren ztun Betrieb 
derart, dass die Konf igurationen der VPU zusammen mit dem aus- 
zufOhrenden Programm der CPU in einen Speicher geladeri werden. 
Die CPU kann wShrend der Ausfuhmng des Programmes die VPU auf 
die Speicherstellen verweisen (z.B. durch Angabe der Adressen 
Oder Pointer) , die die jeweils auszuf(ihrenden Konf igurationen 
beinhalten. Die VPU kann daraufhin die Konf igurationen selb- 
standig und ohne weitere Einflufinahme durch die CPU laden. Die 
Ausffihrung startet sofort oder ggf • durch eine. zus§tzliche In- 
formation (z.B, Interrupt und/oder Start- Befehl) durch die 
CPU. 
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In einer besonders bevorzugten Erweiterung kann die VPU selb- 
st&ndig innerhalb eines Speichers Daten lesen \ind schrelben. 

In einer besonders bevorzugften Erweiterung kann die VPU eben- 
falls selbstandig neue Kohf igurationen aus dem Speicher laden 
und sich bei Bedarf neu konfiguriereri, bhne dass as eines we i- 
teren Einflusses durch die CPU bedarf.. 

Diese Ausgestaltungen ermoglichen einen weitestgehend von CPUs 
unabhangigen Betrieb von VPUs. Lediglich ein Synchronisations- 
austausch zwischen CPU uhd VPU, der bevorzugt bidirektional 
stattf inden kann; sollte zusatzlich vprgesehe?a werden, um die 
Datenverarbeitungen und/oder Konf igurationsausfOhrungen auf- 
eineuider abzustimmen . 

£s wurde weiter erkannt, da& Verfahren zur Datenverarbeitiing 
bevorzugt so ausgelegt werden kdnnen und/oder sollen, dafi je- 
weils fiir die rekonf igurierbare Zielarchitektur (VPU) beson- 
ders geeignete Teile (VPU-CODE) des zu ubersetzenden Program- 
mes identif iziert und extrahiert werden, um eine besonders ef- 
fiziente Datenverarbeitung zu ermoglichen. Diese Teile sind 
entsprechend zu partitionieren und die Konf igurat ion der ein.- 
zelnen iPartitionen ist in ih^ zeitldLchen Reihenfolge zu 
steuern. 

Die verbleibenden Teile des Programmes konnen auf eine konven- 
tionelle Prozessorarchitektur (PROZESSOR) {ibersetzt werden. 
Dies geschieht bevorzugt dergestalti daS diese Teile als Roch- 
sprachencode in einer Standard-Hochsprache (z. B. ANSI C) der- 
art ausgegeben wisrden, daS ein gewdhnlicher (ggf . bereits exi- 
stierender) Hochsprachencompiler diese ohne weiteres verarbei- 
ten kann. 
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Weiterhin sei angemerkt, daS die Verfahren auch auf Gruppen 
von inehreren Bausteinen smgewendet werden k6nnen, 

Insbesondere kaiin eihe Art "Double -Buff ering" zur besonders 
einfachen uhd zugleich schhellen Rekonf iguration angewendet 
werden, in welchem eine Mehrzahl von VPUs vorgesehen sind, wo- 
bei ein Teil der VPUs zu einer Zeit rekonf icfuriert werden 
kann, zu welcher ein anderer Teil rechnet und moglicherweise 
ein Weiterer etwa inaktiv sein kann. Die Daten-, Trigger-/ 
Statusverbindungen etc. werden zwischen der Mehrzahl von VPUs 
geeignet ausgetauscht und ggf . durch adressierte Busse 
und/oder jyiultiptexer/Demultiplexer eiitsprechexid der aktuell 
aktiven und/oder zu rekonf igurierenden VPUs verschaltet. 

Ein Vorteil dieses Verfahrens liegt darin, dafi bestehender 
Code, der far einen beliebigjsn PR02ESS0R geschrieben wurde, 
unter Einbeziehxmg einer VPU weiterverwendet werden kann und 
keine oder nur vergleichsweise geringe Modif ikationen durchge- 
fiihrt werden mussen. Die Modif ikationen konnen zudem schritt- 
weise erfolgen, wobei nach und nach immer mehr Code von dem 
PROZESSOR auf die VPU ubertragen werden kann. Da§ Projektrisi^- 
ko sinkt xmd die tJberschaubarkeit steigt wesentlich an. Es 
. wird darauf hihgewiesen, daS einer derart;ige;h sukzessive Ober- 
tragung von immer mehr Aufgaben auf die VPU, d.h. auf das in- 
tegrale multidimensionale partiell rekonf igurierbaren insbe- 
sondere grobgranulare Feld an Elementen, eine besondere Bedeu- 
tung far sich hat und far sich als erfinderisch angesehen wird 
aufgrund seiner gravierenden Vorteile bei der Systemportie- 
rung. 

Weiterhin kann der Programmierer in seiner gewohnten Entwick- 
lungsumgebung arbeiten und muS sich nicht auf eine neue, mog- 
licherweise fremde Entwicklungsumgebung einstellen. 

8 
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Ein erster wesehtlicher Aspekt der vdriiegeriden Erf indung ist 
darin zu sishen, daS ein PROZESSOR derart mit einer oder mehire-. 
ren VPU(s) verbunden wird, daS ein effizienter Informations- 
austausch, insbesondere in Form von Dateh^ uhd Statusinforma- 
tioh mdglich ist. 

Der Anordnung eines herkommlichen Prozessors und eines rekon- 
f igurierbaren Prozessors, dergestalt, daS ein Austausch von 
Daten- und/oder Statusinformation zwischen denselben wahrend 
der Abarbeitung eines oder mehrerer Progranmie moglich ist 
und/oder ohne daS insbesondere die Datenverarbeitung auf dem 
rekonfigurierbaren Prozessor und/oder dem herkommlichen Pro- 
zessor signifikant unterbrochen werden mufi, sowie der Ausbil- 
dung eines derartigen Systems, wird gleichfails fdr sich Be- 
deutung zugemessen* 

Es kdnnen zunachst beispielsweise eines oder alia der folgen- 
den Verbindungsverfahren und/oder -mittel verwende^t werden: 

a) Shared-Memory 

b) Netzwerk (beispielsweise Bussysteme . wie z .B . PCI -Bus , Se- 
rielle Busse wie z.B. Ethernet) 

c) Kopplung an einen intemen Registersatz . oder mehrere* in- 
teren Registersatze 

d) andere Speichermedien (Festplatte, Flash-ROM, etc.) 

Prinzipiell kann auch die VPU und/oder CPU selbstlLndig ohne 

Zuhilfenahme eines DMAs auf den Speicher zugreifen. Der ge- 

meinsame Speicher kann insbesondere auch als Dualport- oder 

Mult iport speicher ausgestaltet sein. Dem System kdnnen weitere 

Baugruppen zugeordnet werden, insbesondere k5nnen rekonfigu- 

rierbare PPGAs eingesetzt werden, urn eine feingranulare Verar- 

beitung von einzelner Signale oder Datenbits zu ermoglichen 
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und/oder flexible adaptierbare Interface (z-B. diverse seriel- 
le Schnittstellen (V24, USB, etc.), diverse parallele Schnitt- 
stellen, Pestplattenschhittstellen, Ethernet, Telekommimikati- 
onsschnittstellen (a/b, TO, ISDN, DSL, etc) ) auf bauen zix k6?i- 
nen. 

Der Aufbau einer VPU ist beispielsweise bekannt aus den o. g. 
zitierten Anmeldungen. Versuche zu altemativen Bausteindef i- 
nitionen sind beispielsweise unter dem Namen Chameleon gefuhrt 
worden. VPUs lassen sieh auf iinterschiedliche Weise in ein Sy- 
stem integrieren. Ein AnschluS an einen Hostprozessor ist bei- 
spielsweise moglich. Je liach Verf ahren kaim der Hostprozessor 
die Konfigurationskontrolle (HOSTRECXDNP) mit Clbemehmen (z. B. 
Chameleon) oder, z. B,, eine dedizierte Einheit (CT) zur 
Steuerung der (Re)Konf iguration bestehen. 

Entsprechend generiert der tJbersetzer geniafi dem beschriebenen 
Verfahren die Steuer information ffir die Rekonf iguration fur 
eine CT und/oder einen HOSTRECONF. 

Es kann nun das Ubersetzungsprinzip derart ausgestaltet sein, 
daS aus einem PROGRAMM mittels eines PRAPROZESSORS die Teile 
extrahiert werden, die sich auf die jeweils bestimmte (n) 
VPU(s) effizient und/oder sinnvoll abbilden lassen. Diese Tei- 
le werden in ein fur VPUs geeignetes Format transformiert 
(NML) und dann weiter in einen Objektqode iibersetzt. 

Der verbleibenden Code \ind/oder der* extrahierte Code wird er- 

fahningsgemas an oder bezQglich der Stelle der durch die Ex- 

traktion fehlenden Code-Teile urn einen Interface-Code erwei- 

tert, der entsprechend der Architektur des Zielsystems die 

Kotomunikation zwischen PROZESSOR(en) und VPU(s) steuert. Der 

verbleibende und ggf . erweiterte Code kann . bevorzugt 
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trahiert warden sollen. Beispielsweise kann dies folgenderma- 
Sen erf olgen : 



Code 

# START_^EXTRACTION 

Zu extrahierender Code 

# END_EXTRACTION 
••• 

. .- Code. . ■ . 

^11 START^EXTRACTION'' kemizeichn^t den Beginn eines zu extra- 
hlerenden Codes* 

„l I END^EXTRACTION* kennzeichnet das Ende eines zu. extrahie- 
renden Code. 

In einem solchen Fall ist die Einheit zur Umsetzung des Pro- 
gramms in Konf igurationscodes dazu ausgebildet, die Hints be- 
ziehungsweise Umsetzungsvorgaben zu erkennen. 

Es ist auch moglich, dafi zur Extraktion durch Aufruf von NML- 
Routinen Telle des PROGRAMMES direkt in NML .in5>lementiert wer- 
den und in die NMLr Rout inen durch Aufrufe (calls) gesprungen 
wird. Beispielsweise erfolgt dies derart: 

a) NML-Code- 

procedure EXAMPLE 
begin 

end 
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b) PROGRAMM Code 

Code 

call EXAMPLE // Auf ruf des NML-Codes 

Code 

In diesem Fall ist die Einheit zur Umsetzung dazu ausgebildet, 
NML-Progranimteile, das heiBt Progranunteile zur AusfGhning in 
/und/oder auf einem rekonf igurierbaren Array in ein grSSeres 
Programm einzubinden. 

Es ist weiter altemativ und/oder zusatzlich eine Extraktion 
aus einer objektorientierten Klasse raoglich. Fiir eine VPU ge- 
eignete Makros werden als Klasse in der Klassenhierarchie ei- 
ner objektorientierten Prograiraniersprache definiert. Die Ma- 
kros kSnnen dabei: durch Annotation derart gekennzeichnet sein, 
dafi sie als fiir eine VPU bestimmte Codes erkannt und entspre- 
chend - auch in hpheren Hierarchien der Sprache - weiterverar- 
beitet werden. 

Innerhalb eines Makros ist bevorzugt eine. bestimmte Vemetzung 
und/oder Abbi Idling durch das Makro vorgegeben, die sodann die 
Abbildung des Mcdcros auf die VPU bestiramt. 

Durch die Instant iierung und Verkettung der Klasse entsteht 
eine Implementierung' der Funktion, bestehend aus mehreren Ma- 
kros auf der VPU. Mit anderen Worten definiert die Instant iie- 
rung und Verkettung der Makros die Abbildung und Vemetzung 
der einzelnen Operationen aller Makros auf der VPU und/oder 
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ggf . die Vernetzxang xind/oder den Datenaustausch zwischen Vpu 
und CPU. . 

Die Interfacecodes werden bei d.ef Instantiierung hinzugefugt . 
Die Verkettung beschreibt das detaillierte Mapping der Klasse 
auf die VPU. 

Bine Klasse kann beispielsweise auch als ein Aufruf einer Oder 
mehrerer NML-Routinen gebiidet werden. 

a) Klassen-Code 



class EXAMPLE 
begin 

end 

b) PRCXSRAMM Code 

Code 

• • • • . 

EXAMPLE var () // Instantiierung d^r; Klasse 

■ • • 

Code 

• • • 

Es ist weiter auch eine Ext3?aktion durch Analyse m&glich. 
Durch an die jeweilige VPU angepaSte Analysemethoden werden 
Teile innerhalb des PROGRAMMES erkannt, die effizient xind/oder 
sinnvoll auf die VPU abbildbar sind. 
Diese Teile werden aus dem PROGRAMM extrahiert. 
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Eine beispielsweise f\ir viele VPUs geeignete Analysemethode 
ist der Aufbau von Diterif iufi- iind/oder KontrolIfluiSgraphen aus 
dem PROGRAMM. Diese Graphen kdnnen hirisichtlich ihrer m6gli- 
chen Partitionierung und/oder Abbildung auf dieZiel-VPU auto- 
matisch imtersucht werdeii. in diesem Fiall warden die Tisile der 
generierten Grapheii bzw. die entsprechendeii PROGRAMMTEILE/ ex- 
trahiert/ die sich hinreichend gut partitionieren und/oder ab- 
bilden lassen, Hierzu kann eine Partitionierbarkeits- und/oder 
AbbildbarkeitScUialyse erfolgen, die die jeweilige Eigenschaft 
bewertet Entsprechend dieser Bewertung erf olgt dann die Parti- 
.tionierung und Extraktion der Programmteile auf die VPU, sowie 
das Einfuhren der vorgesehenen Interfaces. - 

Es soil ausdrflcklich auf die in der Patentanmeldung DE 101 39 
170.6 beschriebenen Ana ly seme thoden verwiesen werden, die bei- 
spielsweise zur Anwendung koiranen kdnnen. Die vorerwShnte An- 
meldung ist zu Of fenlegungszweckung vollumfanglich eingeglie- 
dert. 

Eine mogliche Analysemethode ist auch durch Erkennting bestimm- 
ter Datentypen gegeben, 

Unterschiedliche Datentypen eignen sich mehr oder weniger gut 
fur die Bearbeitung auf einer VPU. Beispielsweise ist eine 
komplexe Pointer-Arithmetik, bzw. eine pointerbasierende Da- 
tenadressierung (pointer) schwer auf eine VPU abbildbar, wah- 
rend sich Arrays (array) sehr gut abbilden lassen.. 

Erf indungsgemas kdnnen daher weitgehend automatisch oder manu- 
ell die jeweils geeigneten Datentypen und zumindest wesentli- 
che Teile von deren Datenverarbeitung auf eine VPU flbertragen 
und entsprechend extrahiert werden. Die Extraktion erf olgt da- 
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mit ira Ansprechen auf das Auftreten bestimmter Datentypen 
und/oder Datenoperationen. 

Es soli ervahnt werden^ dafi zusatzliche, den Datentypen zuge- 
ordnete Parameter weitere Hinweise zur Bestimmung der Ausfiihr- 
barkeit und/oder Ausfxihrungsperformance auf einer VPU geben 
konnen und daher maSgeblich zur Extraktion mitverwendet werden 
konnen. Beispielsweise spielt die Gr6Be von zu berechnenden 
Arrays eine wesentliche Rolle. £s lohnt sich zumeiat nicht, 
kleine Arrays auf einer VPU zu berechnen, da hier der Synchro- 
nisations- und Datenaustauschaufwand zyischen CPU und VPU zu 
hoch sein kcuih. EinschrSnkend . ist aber dabei wiederum zu er- 
wahnen, daS kleine Arrays, die iimerhalb einer Schleife beson- 
ders hSuf ig verrechnet werden^ sich dennoch sehr gut far VPUs 
eignen, insofem die Schleife weitestgehend komplett auf der 
VPU berechnet wird. GroSe Arrays kdnnen dagegen zumeist ohne 
weiteres auf einer VPU besonders performant berechnet werden. 

Weiterhin soil erwahnt werden, daS besondere Datentypen durch 
einen besonders angepafiten Compiler oder ggf . durch einen An- 
wender (2. B. mittels TYPE in Pascal) erstellt werden kdnnen, 
die sich . besonders f ilr VPUs eignen und deren Datenverarbeitung 
dann auf einer VPU ausgeffl^^ 

Beispielsweise konnen folgende Datentypen bestehen: 
TYPE streaml of Byte [] ; 
TYPE stream2 of Byte [0..255; 

Stream def iniert einen Datenstrom (stream)* von in der Regel 
groSer,. ggf. nicht vorbekannter und/oder unendlicher Lange. • 
Streaml hatte hier eine nicht vorbekannte Lange. Beispielswei- 
se konnte ein mit diesem Datentyp programmierter FIR-Filter 
(Oder z. B. eine FFT oder DCT) automatisch - und ggf ausge- 

walzt - auf eine VPU abgebildet werden. Die Rekonf iguration- 
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erfolgt dann typisch und bevorzugt im Ansprechen auf andere 
Mechanismeii. alis den Datenstromverlauf ^ z.b. durch zahler, Ver 
gleicher, CT-gesteuert und/oder durch Time-Out. Soil hierbei 
etwa eine Wave- oder andere Rekonf iguration ausgel6st werden, 
so kann diese iiber eine durch vorgenannte Methoden veranlaSte 
Kennzeidhnxmg eirxes Datenpaketes, insbesohdere Datenbytes, ali 
ein letztes zu sein erfolgen urn nach uiid/oder mit dem Durch- 
lauf dieses als letzes Datenpaket gekennzeichneten Datenpake- 
tes die Rekonfiguration auszulosen. 

streaTti2 definiert einen Datenstrom der Lange von hier 256 
Byte, der wie streaml behandelt werden kann, jedoch die Eigen- 
schaft aufweist, nach 256 Byte zu enden und damit nach Beendi- 
gang mdglicherweise eine Rekonfiguration im Sinne der vorab 
zitierten Patente selbigen Anmelders ausldsen kann. Insbeson- 
dere kann eine Wave -Rekonf iguration (z. B- nach DE 197 04 
728.9, DE 199 26 538.0, DE 102 06 857.7, DE 100 28 397.7) mit 
detn Eintreffen des let z ten Dat en-Bytes ausgelost werden und 
mit der Verarbeitung dieses letzten Daten-Bytes die jeweilige, 
das Byte verarbeitende PAE rekonf iguriert werden. 

Eine f<ir die implementierte VPU geeignete tJbersetzung des ex- 
trahierten Codes nach NOTi kann bevorzugt durchgefuhrt werden.. 

Pur datenfluiSorientierte VPUs kann beispielsweise autpmatisch 
ein DatenfluS- und/oder Kontrollf luSgraph aufgebaut werden. 
Die Graphen werden daiui in NML-Code fibersetzt. 

Entsprechende Code-Teile wie z. B. Schleifen kdnnen mittels 

einer Datenbank (Lookup) libersetzt werden oder gew6hnliche 

Transformationen k6nnen durchgefuhrt werden. Fiir Codeteile 

konnen auch Makros vorgesehen sein, die dann gemaS den in vor- 

genannten Anmeldungen offenbarten IKR weiterverwendet werden. 
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Ebenfalis kann die Modular isierung nach PACT13/ Fig. 28 unter- 
stixtzt werden. 

Gegebenenfails kann bereits das Abbilden auf die VPU bzw. des- 
sen Vorbereitung effolgenr beispielsweise mittels der Durch- 
fuhrung des Plazierens der bendtigten Ressourcen und des Rou- 
tens der Verbindungen (Place and Route) . Dies kann zum Bei- 
spiel nach per se bekannten Regeln des Plazierens und Routens 
geschehen. 

Ea ist auch indglichy mittels. einer automatischen Analysemethd- 
de den extrahierten Code und/oder den iibersetzten NML-Code auf 
seine Verarbeitungsef f izienz bin zu cuialysieren. Dabei ist die 
Analysemethode bevorzugt so gewahlt, dafi der Interface -Code 
und die daraus entstehenden Performanceeinflflsse an geeigneter 
Stelle mit in die Analyse einfliefen. Geeignete Analyseverfah- 
ren sind insbesondere in den vorgenannten Anmeldungen der vor- 
liegenden Anmelderin beschrieben. 

Gegebenenfalls wird die Analyse durch eine komplette Uberset- 
zung und Implementierung auf dem Hardware -System durchgefiihrti 
indem das PRGGRA>n^ ausgefOhrt xind mit geeigneten Methoden, wie 
sie beispielsweise nach dem Stand der Technik bekannt sind, 
vermessen wird. 

Es ist weiter moglich, daS basierend auf den durchgefiihrten 
Analysen, verschiedene durch die Extraktion fiir eine VPU ge- 
wahlte Telle als ungeeignet identifiziert werden kSnnen. Umge- 
kehrt kann die Analyse ergeben, dafi bestimmte, far einen PRO- 
2ESS0R extrahierte Telle zur Ausfuhrung auf einer VPU geeignet 
waren . 
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Eine optionale Schieife, die nach der Analyse basierend auf 
geeigneten Entscheidungskriterien zuruck in den Extraktions- 
teil fflhrt, um diesen mit entsprechend der Analyse angepaSten 
Ext rakt ions vorgaben eiiieut auszufuhren, ermoglicht die ppti- 
mierung des tnbersetziingsergebnisses • Man hat somit eihe Itera- 
tion. Dieses Vorgehen ist bevorzugt. 

Eine Schieife kann an mehreren unterschiedlichen Stellen in 
den Compilerlauf eingebracht sein, 

Der erhaltene NML-Code ist bei Bedarf entsprechend den Eigeh- 
ischaf ten der yerwendeten VPU zu partitionieren, d.h. in ein- 
zelne Teile zu zerlegen, die auf jeweils in die vorhandenen 
Ressourcen abgebildet werden konnea. 

Eine Vielzahl derartiger Mechcmismen, insbesondere auf Gra- 
phenanalyse basierende, sind nach dem Stand der Technik per se 
bekannt. Eine bevorzugte Variante basiert jedoch auf der Ana- 
lyse der Prograramsourcen und ist unter dem Begrif f temporal 
Partitioning bekannt. Dieses Verfahren ist in der genannten 
PHD-Thesis von Cardoso beschrieben, die zu Of fenbarungszwecken 
vollumfSnglich eingegliedert wird. 

Partitionierxmgsverf ahren gleich welcher Art sind entsprechend 

des verwendeten VPU-Types zu adapt ieren, Liegen VPUs vor, die 

die Speicherung von Zwischenergebniss^n in Register und/oder 

Speicher zulassen, ist durch die Partitionierung die Binbin- 

dong der Speicher zur Speichenmg von Daten und/oder Zustanden 

zu berficksichtigen. Die Partitionierungsalgorithmen (z. B. die 

temporale Partitionierung) sind entsprechend zu adapt ieren. 

Gewdhnlicherweise wird die eigentliche Partitionierung und das 

Scheduling durch die genannten Patente jedoch erheblich ver- 

einfacht und erst, sinnvoll ermoglicht. 
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Manche VPUs bieten die Moglichkeit der dif f erentieilen Rekon- . 
figuration. Diese kann angewendet werden, wenn nur verhaltnis- 
maSig wenige. Anderungen innerhalb der Anordnung der PAEs bei 
einer Rekonf iguration notwendig werden. Mit anderen Worten 
werden hur die Veranderiihgen einer Kohf iguration gegeniiber der 
aktuellen Konf iguration rekonf iguriert. Die Partitionierxing 
kann in diesem Fall dergestalt sein, daS die auf eine Konf igu- 
ration folgende, gegebenenfalls dif f erentielle Konf iguration 
hur die notwendigen Rekonf igur at ionsdat en enthalt und keine 
vollst&ndige Konf iguration darstellt. Ea iet moglich, den Kon- 
figurat ionsdat enoverhead zu Analysezwecken bei der Beurteilung 
der Aufteilungsef f izient mit zu berClcksichtigen. 

Die Schedulingmechanismen fur die partitionierten Codes konnen 
derart erweitert werden, daS das Scheduling durch Ruckmeldun- 
gen der VPU an die jeweils rekonf igur ierende Einheit (CT 
und/oder HOSTRECONF) gesteuert wird, Insbesondere wird dabei 
bei der Partitionierung die sich daraus ergebende Mdglichkeit 
der bedingten Ausfuhrung, d. h. der expliziten Bestimmung der 
nachf olgenden Partition durch den Zustand der aktuellen Parti- 
tion genutzt* Mit anderen. Worten ist es moglich, die Partitio- 
nienmg derart zu optimieren> dafi bedingte Ausfuhningen' wie z. 
B. IF, CASE etc. berucksichtigt werden, 

Werden VPUs verwendet, die die FShigkeit besitzen Statussigna- 

le zwischen den PAEs zu tibertragen, wobei PAEs auf die jeweils 

^ertragenen Zustinde reagieren und/oder diese mitverarbeiten, 

kann innerhalb der Partitionierung und des Schedulings zudem 

die bedingte Ausfuhrting innerhalb der Anordnung der PAEs, also 

ohne die Notwendigkeit einer vollstSndigen oder teilweisen Re- 

konfiguration aufgrund eines geSnderten bedingten Pro- 

grairanablauf s,. benlcksichtigt werden. 
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Weiterhin kann das Scheduling die Mdglichkeit des Vorladens 
von Konfigurationen wahrend der Lauf zeit einer anderen Konfi- 
guration unterstutzen. Dabei kSnnen mehre re Konfigurationen 
mSglicherweise auch spekulativ vorgeladen werden, d. h. ohne 
daS sichergestellt ist, daS die Konfigurationen ilberhaupt be- 
notigt werden. Durch Selektionsmechanismen k6nnen dann zur 
Laufzeit die zu verwendenden Konfigurationen ausgewahlt werden 
(siehe auch Beispiel NLS in DE 100 50 442.6, EP 01 102 674*7) 

Eine zusStzliche Oder alternative Variante sieht vor, dass die 
Datenverarbeitung innerhalb der an die CPU gekoppelten VPU ex-^ 
akt gleichviele Takte benotigt, wie die Datenverarbeitung in- 
nerhalb der Rechenpipeline der CPU. Insbesondere bei modemen 
Hochleisttangs-CPUs tnit einer Vielzahl von Pipelinestufen (>20) 
kann dieses Konzept ideal eingesetzt werden. Der besondere 
Vorteil ist, dass keine besonderen Synchronisationsmechanismen 
wi(B z.B. RDY/ACK notwendig sind und/oder keine Anpas sung von 
Opcodes zur Registersteuerung erforderlich ist. Der Compiler 
hat bei diesem Verfahren sicherzustellen, dass die VPU die er- 
forderliche Anzaihl an Takten einhalt uiid ggf . die Datenverar- 
beitung durch das Einfugen von Verzogerungsstufen wie z. B. 
esinen EalirThrough FIFOs auszubalancieren wie er in anderen; 
vorerwShnten Anmeldtingen beschrieben ist. 

Der ausgegebene Code ist ublicherweise vollstandig und bevor- 
zugt ohne weitere Eingriffe auf den jeweils nachfolgenden Cpm- 
pilem verarbeitbar. Gegebenenfalls kdnnen Compilerf lags \ind 
Constraints zur Steuerung nachfolgender Compiler generiert 
werden, wobei der Anwender falls gewiinscht. optional eigene 
Vorgaben hinzufugen und/oder die generierten Vorgaben modifi- 
zieren kann. Die nachfolgenden Compiler bendtigen keine we- 
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sent lichen Modif ikationen, so dafi per se bekannte Standard- 
Tools prinzipiell e inset zbar sind. 

Das yorgeschlagene Verf ahren eignet sich somit beispielsweise 
insbesondere als PrSprozessor bzw. Praprozessorverf ahren vor 
Compiiem und Entwicklungissystemen. Es soil aber ausdriicklich 
erwahnt werden, daS prinzipiell anstatt und/oder zusanmien mit 
den zuvor beschriebenen Obersetzers auch Compiler nach PACTll 
eingebunden werden konnen. 

An die beschriebene Architektur, insbesondere direkt an die 
VPU kanii ein FPGA gekoppelt sein, um feingranulare Datenverar- 
beitting zu ermoglichen und/oder ein flexibel adaptierbares In- 
terface (z.B. diverse serielle Schnittstellen (V24, USB, 
etc.), diverse parallele Schnittstellen, Festplattenschnitt- 
stellen, Ethernet, Telekommunikationsschnittstellen (a/b, TO, 
ISDN, DSL, etc)) zu weiteren Baugruppen zu e3rm6glichen . 
Der FPGA kann dabei aus der VPU-Architektur, insbesondere 
durch die CT, xind/oder durch die CPU konfiguriert werden. Der 
FPGA kann statisch, also ohne Rekonf iguration zur Laufzeit 
und/oder dynamisch, also mit Rekonf iguration zur Laufzeit, be- 
trieben weirden. 

Es wurde bereits das Vorsehen eines Interface - Code angespro- 
chen. Der Interface -Code, der in den extrahierten Code einge- 
setzt wird, kann durch unterschiedliche Verf ahren vorgegeben 
werden. Bevorzugt wird der Interface- Code in einer Datenbank 
abgelegt, auf die zugegriffen wird. Die Einheit zur Umsetzung 
kann so ausgebildet sein, dafi sie eine Auswahl, etwa des Pro- 
gramraierers, berGcksichtigt , bei der beispielsweise durch Hin 
weise im PROGRAMM oder durch Compilerf lags der passende Inter 
face-Code ausgewShlt wird. Dabei kann ein fur das jeweils ver- 
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wendete In?)lementierungsverfahren des VPU/ CPU- Systems geeigne-- 
ter Interface - Code gewShlt werden.! 

Die Datenbank selbst kann durch unterschiedliche Methoden auf- 
geb^ut und gewartet werdeh. Einige Beispiele sollen zur Ver- 

deutlichung der Mdglichkeiten arigef werdeh: 

J 

a) Der Interface -Code kann vom Lief eranten des Compilers fur 
bestimmte Verbindungsverf ahren zwischen VPU und CPU(s) 
vorgegeben werden. Dies kann bei der Organisation der Da- 
tenbank berucksichtigt werden, indem entsprechende Spei- 
chermittel fur diese Angaben bereitgehalten wierden. 

b) Der Interface "Code kann vom Benutzer, der den Systemaufbau 
best immt hat, selbst geschrieben oder aus bestehenden 
(Beispiel-) Interface -Code modifiziert und der Datenbank 
zugefugt werden. Das Datenbankmittel wird hierzu bevorzugt 
benutzermodifizierbar gestaltet, xm dem Benutzer die Da- 
tenbankmodifikation zu ermoglicben. 

c) Der Interface -Code kann von eine Entwicklungs system, mit 
dem beispielsweise der Systemaufbau des VPU-CPU-Systems 
geplant imd/oder beschrieben und/oder getestet wurde, au- 
tomat isch generiert werden. 

Der Interface- Code is t gewohnlicherweise bevorzugt derart ge- 
staltet, daS er den Anf orderungen der Progpammiersprache ent- 
spricht, in der der extrahierte Code vorliegt in den der In- 
terface-Code eingefiigt werden soil- 

Debugging und Integration der Toolsets 

In die Interface -Codes k6imen Kommunikationsroutinen einge- 
filhrt werden, urn die unterschiedlichen Entwicklungssysteme fQr 
PROZESSOR land VPU zu synchronisieren. Insbesondere kann Code 
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fxir die jeweiligen Debugger (z. B. nach PACTll) aufgenommen 
werden* 



per Iriterf ace-Code ist so ausgebildet, dafi er den Datenaus- 
tausch zwischen PROZESSOR und VPU ermoglicht und/oder steuert . 
Er ist daher eine geeignete und bevorzugte Schnittstelle, urn 
die jeweiligen Entwicklungssysteme und Debugger zu steuern. Es 
ist beispielsweise moglich, einen Debugger f\ir den PROZESSOR 
isolange zu aktivieren, wie die Daten von dem Prozessor verar- 
beitet werden- Sobald die Daten fiber den Interface -Code an ei- 
ne (Oder mehrere) VPU ubergeben werden, ist ein Debugger fiir 
VPUs zu aktivieren. Wifd der Code zuriick ah den PROZESSOR ge- 
sendet, soil wiederum der PROZESSOR-Debugger aUctiviert werden. 
Es ist daher also mdglich und bevorzugt, derartige AblSufe 
durch das Einfugen von Steuercodes f\ir Debugger und/oder Ent- 
wicklungssysteme in den Interface-Code abzuwickeln. 

Die Kommunikation und Steuerung zwischen den unterschiedlichen 
Entwicklungssystemen soil daher bevorzugt mittels in die In- 
terface-Codes von PROZESSOR und/oder VPU eingebrachte Steuer- 
codes abgewickelt werden. Die Steuercodes kSnnen dabei beste- 
henden Standards ffir die Steuerung ' von Entwicklungssystjemen 
weitgehend entsjprechen. 

Die Verwaltung und Kommunikation der Entwicklungssysteme wird 
vorzugsweise wie beschrieben in die Interface -Codes abgewik- 
kelt,.kann jedpch - sofem sinnvoll - auch getrennt von die- 
sen, nach einem entsprechenden ahnlichen Verfahren abgewickelt 
werden. 



In vielen Programmiersprachen, besonders in sequentiellen wie 

z. B. C, wird eine.exakte zeitliche Reihenfolge implizit durch 

die Sprache vorgegeben. Bei sequentiellen Programmiersprachen 
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geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anwieisungen. Sot em durch Prograiraniersprache iind/oder 
deri Algorithmus erforderlich, lafit sich die Zeitinformation 
auf Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK Oder 
ein Time-Stamp- Verfahren abbilden. * 

Beispielsweise wird eine nachfolgende for-Schleife nur dann 
durchlaufen vmd iteriert, wenn eine Variable, hier input stream 
je Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus> wird 
der Schleifendurchlauf bis zum Eintreffen RDY angehalten: 

while TRUE- 
S := 0 

for i: 1 to 3 

s := s + inputstream; 

Die Eigenschaft der sequent iellen Sprachen, nur von der Be- 
fehlsverarbeitung gesteuert zu werden, wird mit dem DatenfluS- 
prinzip die Verarbeitung durch den Datenstrom, bzw, die Bxi- 
stenz von Daten zu steuem verbunden. Mit auideren Worten wird 
ein Befehl und/oder eine Anweisung (z. B. s s + 
inputstream;) nur verarbeitet, wenn die Operation ausgefuhrt 
werden; kann und die Daten verfugbar sind. 

Bemerkenswert ist, daS dieses Verfahren gew6*hnlicherweise zu 
keiner Andening der Syntax oder Semantik einer Hochsprache 
ffthrt. 

Kotnplexere Punktionen einer Hochsprache, wie z. B. Schleifen, 
werden durch Makros realisiert. Die Makros werden vom Compiler 
vorgegeben und zur Obersetzungszeit instantiiert . 
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Die Makros sind entweder aus einfachen Sprachkonstrukten der 
Hochsprache Oder auf Assemblerlevel aufgebaut . Makros koniien 
parametriert sein, urn eine einfach Adaption an den beschriiBbe- 
nen Algorithmus zu erm6glichen. (ygl. auch PACTll) 

Ein Standardprozessor z.B. ein RISC, CISC, DSP (CPU) wird also 
mit einem rekonf igurierbaren Prozessor (VPU) gekoppelt. 

Zwei xmterschiedliche, bevorzugt jedoch auch zugleich imple- 
mentierbare Koppliingsvarianten konenn wie folgt beschrieben 
•sein, 

Eine erste Variante sieht eine direkte Ankoppel\ing an den Be- 
fehlssatz einer CPU vor (Befehlssatzkoppltmg) • 
Eine zweite Variante sieht eine Ankoppeliing Clber Tabellen im 
Hauptspeicher vor. Es sind also Tabelleninittel vorgesehen. 

Innerhalb eines Instruktionssatzes (ISA) einer CPU sind fur 
gewohnlich freie unbenutzte Befehle vorhanden, Einer oder eine 
Mehrzahl dieser freien unbenutzen Befehle wird nunmehr fiir die 
Steuerung yon VPUs verwendet (VPUCODE) . 

Durch die Dekodierung eines VPUCODEs* wird eine Konf igurations- 
einheit (CT) einer VPU angesteuert die in Abhangigkeit des 
VPUCODEs bestimmte. AblSuf e ausfQhrt. Es ist also eine zur VPU- 
Decodierung ansprechbare CT vorhanden. 

Beispielsweise kann ein VPUCODE das Laden und/oder Ausfuhren 
von Konfigurationen durch die Konf igurationseinheit (CT) fiXr 
eine VPU ausldsen. 
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In einer erweiterten Ausfiihrung kann ein VPUCODE uber eine 
Obersetzungstabelle, die bevorziigt: von der CPU, altemativ 
aber auch von der Oder einer VPU Oder einer extemen Einheit 
aus yerwaltet wird, auf unterschiedliche VPU-Koimnandos iiber- 
setzt werden 

Die Konfigurationstabelle kaim in T^hSngigkeit von dem ausge- 
fuhrten CPU Programm oder Codeabschnitt gesetzt werden. 

Die VPU ladt nach Eintreffen eines Ladekommandos Konf iguratio- 
nen aus einem eigenen oder mit der CPU geteilten Speicher. 
Insbesondere kann eine VPU-Konfiguration im Code des aktuell 
ausgefuhrten CPU- Programmes beinhaltet sein. 

Nach Erhalt eines Ausffihrungskoramandos fiihrt eine VPU die aus- 
zufClhrende Konfiguration aus und die entsprechende Datenverar- 
beitung durch. Das Beenden der Datenverarbeit\mg kann durch 
ein Terminieiningssignal (TERM) an die CPU angezeigt werden. 
Dazu sind entsprechende Signal lei tungen/ Interrupt -Eingange 
usw. vorhanden und/oder; ausgebildet. 

Das Auftreten eines VPUCODEs konnen solange Wartezyklen auf 
der CPU ausgefiihrt werden, bis das Terminierxingssignal (TERM) 
der Beendigiang- der Datenverarbeitung von der VPU eintrif f t . 

In einer bevorzugtien Ausgestaltung wird mit der Verarbeitung 
der nichsten Codes fortgefahren. Tritt ein weiterer VPUCODE 
auf, kaim sodann auf die Beendigung des vorhergehenden gewar- 
tet werden, oder sSmtliche gestartete VPUCODEs werden in einer 
Verarbeitungspipeline eingereiht, oder ein Taskwechsel wird 
insbesondere wie nachfolgend beschrieben ausgefdhrt. 
Die Beendigung einer Datenverarbeitung wird .durch das Eintref- 
fen des Terminierungssignal (TERM) in einem Statusregister si- 
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gnalisiert- Die Terminienmgssignale treffen in der Reihenfol- 
ge einer mdglichen Verarbeitungspipeline ein. 



Die Datenverarbeitung auf der CPU kann durch das Testen des 
Statusregisteirs auf das Eintrefferi eines Tertninieruixgssigiiales 
synchronisiert werden. 

In einer mdglichen Ausgestaltung kann, sofem eine Applikation 
vor dem Eintreffen von TERM z.B. durch Datenabhangigkeiten 
nicht fortgesetzt werden kann, ein Taskwechsel ausgel5st wer- . 
deri, 

Es ist bevorzugt/ wenn lose Kopplungen zwischen. Prozessoren 
und VPUs aufgebaut sind, bei welchen VPUs weitestgehend als 
unabhUngige Coprozessoren arbeiten. 

Eine derartige Kopplung sieht eine oder mehrere gemeinsame Da- 
tenquellen und -senken, zumeist iiber gemeinsame Bussysteme 
und/oder gemeinsame Speicher vor. Uber DMAs und/oder andere 
Speicherzugrif f skontroller werden Daten zwischen einer CPU und 
einer VPU ausgefcauscht • Die Synchronisation der Datenverarbei- 
tung erfolgt beyprzugt <iber eine Inter^nijptsteueruhg oder eineri 
Statusabfragemechanismus (z.B. Polling) . 

Eine enge Ankopplung entspricht der vorab beschriebenen direk- 
ten Ankopplung einer VPU in den Befehlssatz einer CPU. 

Bei einer direkten Rechenwerk -Ankopplung ist besonders auf ei- 
ne hohe Rekonf igurationsperformance zu achten. Bevorzugt kann 
daher die Wave-Rekonf iguration zum Einsatz kommen. Desweiteren 
werden die Konf igurationsworte bevorzugt vorab derart vorgela- 

den, dass bei Ausfuhrxmg des Befehls die Konf iguration beson- 

27 



wo 02/103532 PCTyEP02/06865 

ders schnell (mittels Wave-Reconfiguration im Optimalfall in- 
nerhalb eines Taktes) konfiguriert werden kanri. Im iibrigen wa- 
re auch mdglich, anstelle eirier Array- Teilkbhfigurat ion bei 
hoch performanten, insbesondere aber auch bei uberwiegend nie- 
derperf ormanten Anwehdungeri mehrere insbesondere identische 
Arrays vorzusehen, von dieseh wehigstens eines f lir eine neue 
Task umzukonfigurieren, insbesondere im Vorgriff , und dann 
nach Bedarf anstelle einer Umkonf iguration oder Teilumkonfigu- 
ration eines integralen multidimensionalen partiell zur Lauf- 
zeit rekonfigurierbaren grobgranularen Feldes einfach auf ein 
anderes Array vollstandig zu wechseln. Signale konnen dabei z. 
B. fiber MUX- /Demuxstuf en den Teilarrays zugefuhrt werden, ins- 
besondere I/O-, Daten-, Status- und/oder Trigger signale. 

Fur die Wave-Reconfiguration werden bevorzugt die voraussicht- 
lich auszufuhrenden Konf igurationen vorab durch den Compiler 
zur Con5>ilezeit erkannt und zur Laufzeit entsprechend vorgela- 
den. 

Zum Zeitptinkt der Bef ehlsausffihrung wird die entsprechende 
Konf iguration gegebenenfalls fiir jede PAE einzeln und/oder f fir 
eine PAE-Teilmenge einzeln selektiert und ausgefuhrt. Auch 
derartige Verfahren sind nach den o.g. Schriften bekannt. 

Eine bevorzugte Implementierung kann unterschiedliche Daten- 
transfers zwischen einer CPU und VPU yorsehenl Drei besonders 
bevorzugte einzeln oder kombiniert einsetzbare Methoden werden 
nachfolgend beschrieben. 

Bei einer Registerkopplung kann die VPU Daten aus einem CPU- 
Register entnehmen, verarbeiten und in ein CPU-Register zu- 
rfickschreiben . 
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Bevorzugt werderi Synchronisationsmechanismen zwischen der CPU 
und der VPU eingesetzt- 

Beispielsweise kann die VPU durch das Einschreiben der Daten 
in ein CPU-Register durch die CPU ein RDY-Signal erhalten und 
daraufhih die eingeschiiebenen Daten verarbeit^n. Das Ausiesen 
von Daten aus einem CPU-Register durch die CPU kann ein ACK~ 
Signal generieren, wodurch die Datenabnahme durch die CPU der 
VPU signalisiert wird. Die Verwendung des per se beksumten 
RDY/ACK-Protokolls in unterschiedlicher AusprSg\ing ist vorlie- 
gend gerade bei grobgranularen Zellen der rekonfigurierbaren 
Einheiten vorteilhaft. 

CPUs stellen typischerweise keine entsprechenden Mechanismen 
2ur Verfugung. 

Zwei m5gliche Ldsungen werden n§her beschrieben: 

Bin einfach zu realsierenden Ansatz ist, die Datensynchronisa- 
tion uber ein Statusregister durchzuf lihren . Beispielsweise 
kann die VPU das erfolgte Ausiesen von Daten aus einem Regi- 
ster und das damit verbundene ACK-Signal und/oder das Ein- 
schreiben. von Daten in ein Register mid das damit verbimdene 
RDY-Signal in dem Statusregister anzeigen. Die CPU testet zu- 
nachst das Statusregister und fiihrt beispielsweise so lange 
Warteschleifen oder Taskwechsel aus, bis - je nach Operation - 
das RDY Oder ACK eintraf . Danach fiihrt die CPU den jeweiligen 
Registerdatentransfer aus. 

In einer erweiterten Ausgestaltung wird der Befehlssatz der. 

CPU urn load/store-Instruktionen mit integrierter Statusabf rage 

(load_rdy, store_ack) erweitert. Beispielsweise. wird bei einem 

store_ack nur dann ein neues Datenwort in ein CPU-Register ge- 
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schrieben, wenn das Register vorher von der VPU ausgelesen 
wurde iind ein ACk eintraf . Entsprechend liest load__rdy nur Da- 
ten aus einem CPU-Register, wenn die VPU vorher neue Daten 
eingeschrieben \md ein RDY generiert hat. 

Daten, die zu einer auszufiihrenden K6nf iguration gehdreri kdn- 
nen sukzessive, quasi durch Block-Moves ahnlich wie nach dem 
Stand der Technik in die CPU-Register geschrieben iind/oder aus 
diesen gelesen warden. Ggf . implementierte Block-Move- 
Instruktionen konnen bevorzugt durch die beschriebene inte- 
grierte RDY/ACK Statusabfrage erweitert werden. 

Es ist of fensichtlich, dass eine Vielzahl von leichten Modifi- 
kationen und unterschiedlichen Ausgestaltungen dieses Gxxind- 
verfahrens mSglich sind. 

Die bereits erwShnte Wave-Rekonf iguration erlaubt das Starten 
eines neuen VPU-Befehls und der entsprechenden Konf iguration, 
sobald die Operanden des vorhergehenden VPU-Befehls aus den 
CPU-Registem abgenonnnen vrurden. Die Operanden fur den neuen 
Be fehl konnen direkt nach Befehlsstart in die CPU-Register ge- 
schrieben werden. 

Entsprechend des Wave-Rekonfiguration-Verfahrens wird die VPU 
successive mit Pertigstellung der Datenverarbeitvuxg des vorhe- 
rigen VPU-Befehls fiir den neuen VPU-Befehl umkonf iguriert imd 
die neuen Operanden verarbeitet. 

Weiterhin konnen Daten zwischen einer VPU und einer CPU durch 
geeignete Buszugriffe auf getneinsame Ressourcen ausgetauscht 
werden , 
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Sofern Daten ausgetauscht werden sollen, die kurz zuvor von 
der CPU verarbeitet wurden iind daher voraussichtlichi noch im 
bevorzugt vorzusehenden Cache der CPU liegen bzw. sofort an- 
schliessend von der CPU verarbeitet werden und daher sinnvol- 
lerweise in den Cache der CPU gelegt werden, werden diese be- 
vorzugt von der VPU aiis dem Cache der CPU gelesen, bzw. in den 
Cache der CPU geschrieben. Dies kann durch geeignete Analysen 
weitestgehend vorab zur Compilezeit der Applikation durch den 
Compiler festgestellt und der Binarcode entsprechend generiert 
werden. 

Sofern Daten ausgetauscht werden sollen, die sich voraussicht- 
lich nicht im Cache der CPU befinden bzw. voraussichtlich 
nicht nachfolgend im Cache der CPU benotigt werden, werden 
diese bevorzugt von der VPU direkt vom extemen Bus und der 
darait verbundenen Datenquelle (z.B. Speicher, Peripherie) ge- 
lesen, bzw. an den extemen Bus und der damit verbtindenen Da- 
tensenke (z.B. Speicher, Peripherie) geschrieben. Dies kann 
durch geeignete Analysen weitestgehend vorab zur Compilezeit 
der Applikation durch den Compiler festgestellt und der Binar- 
code entsprechend generiert werden. 

Bei einem Transfer Ober den Bus am Cache yorbei wird bevorzugt 
ein Protokoll zwischen Cache und Bus implementiert , das fCkr 
einen korrekten Inhalt des Caches sorgt. Beispielsweise kann 
das bekannte MESI -Protokoll nach dem Stand der Technik hierzu- 
verwendet werden. 

Die beschriebenen Verfahren miassen zun^chst keinen besonderen 
Mechanismus fiir die Unterstutzung von Betriebssystemen vorse- 
hen.Es ist nSmlich bevorzugt, sicherzustellen, dass ein aus- 
zufuhrendes Betriebssystem sich entsprechend des Status einer 
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zu unterstutzenden VPU verMlt, was moglich ist und wozu ins- 
besondere Scheduler vorgesehen seiri kSrinen. 



Bei einer engen Rechenwerkkopplvmg wird bevorzugt das Status- 
register der CPU abgefragt, in welches die angekoppelte VPU 
ihren Datenverarbeitiihgsstatus ( Termini erungssignal) eintrSgt. 
Soli eine weitere Datenverarbeitung an die VPU ubertragen wer- 
den, und die VPU hat die vorherige Datenverarbeitung noch 
nicht beendet wird gewartet und/oder bevorzugt ein Taskwechsel 
ausgefuhrt . 

Pur eine Coprozessorkopplung werden bevorzugt uber das Be- 
triebssystem, i.b. den Scheduler gesteuerte Mechanismen ver- 
wendet : 

Ein einfacher Scheduler kann nach Obertragung einer Funktion 
auf eine VPU entweder den aktuellen Task auf der CPU weiter- 
laufen lassen^ sofem dieser xinabhSngig und parallel zur Da- 
tenverarbeitung auf einer VPU ablaufen kann. Sofem oder so- 
bald der Task auf die Beendigung der Datenverarbeitung auf der 
VPU warten muss, schaltet der Taskscheduler auf einen anderen 
Task um. 

Jeder neu aktivierte Task wird, sofem er die VPU verwendet, 
vor Verwendung prufen, ob diese far eine Datenverarbeitung zur 
Verfugung steht und/oder aktuell noch Daten verarbeitet; dann 
soli entweder auf die Beendigung der Datenverarbeitung gewar- 
tet Oder bevorzugt der Task gewechselt werden. 

Ein einf aches und dennoch leistungsfahiges Verfahren kann 
durch sogenannte Descriptor Tables aufgebaut werden, die be- 
spielsweise folgendermafien realisiert werden kdnnen: 
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Jeder Task generiert zum Aufruf der VPU eine Oder mehrere Ta- 
bellefii} (VPUCALL) mit einetn geeigneten festgelegten Datenfor* 
mat in dem ihm zugewieseheri Speicherbereich. Diese Tabelle be-^ 
einhaltet sSmtliche Steuer information fur eine VPU, wie z*B. 
das auszufiihrende Programra / die auszufilhrende Konf iguration 
Hiid/oder Zeig6r auf die Speicherstelle (n) oder Datehquelleii 
der Eingangsdaten und/oder die Speicherstelle (n) oder Daten- 
senken der Ergebnisdaten und/oder weitere Ausftihrungsparame- 
ter, z.B. Datenarraygrofien. 

Im Speicherbereich des Betriebssystems bef indet sich eine Ta- •.. 
belle oder verkettiste Liste (LINKLIST) , die auf sSmtliche 
VPUCALL-Tabellen in der Reihenfolge ihrer Erstellung zeigt. 

Die Datenverarbeitung auf der VPU ISuft nuiunehr derart ab, 
dass ein Task einen VPUCALL erstellt vind Hbev das Betriebssy- 
stem die VPU aufruft. Das Betriebs system erstellt einen Ein- 
trag in der LINKLIST. Die VPU arbeitet die LINKLIST ab und 
fuhrt die jewells referenzierten VPUCALL aus. Die Beendigung 
einer der jeweiligen Datenabarbeitung wird jeweils durch einen 
entsprechenden Eintrag in die LINKLIST und/oder VPUCALL Tabel- 
le angezeigt. 

Die VPU arbeitet somit weitgehend unabhangig von der CPU. Das 
Betriebssystem und/oder die jeweiligen Task mflssen lediglich 
die Tabellen (LINKLIST bzw. VPUCALL) Gberwachen. 

Besonders performanceef f izient arbeiten die beiden Verfahren, 
wenn als VPU eine Architektur zum Einsatz kommt, die eine mit • 
der Datenverarbeitung flberlagerte und/oder iiberlagerbare Re- 
konf iguration zulSsst. 
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Damit ist es mSglich, eine neue Datenverarbeitung und eine 
ggf : dandt verbxmdene Rekonficniratioh sofort. hacli Lesen der 
ietzten Operanden axis den Dateiiquellen zu starten. Mit anderen 
Worten ist fur die Synchronisation nicht mehr das Beenden der 
DatenverarbeitimgV sondem das Lesen der Ietzten Operanden er- 
forderlich. Dadurch wird die Performaiice der Datenverarbeitung 
erheblich gesteigert. 

inen zusatzlichen EinfluB auf die Betrachtung und den Umgang 
mit Zustanden hat der mogliche Einsatz eines Betriebssystemes. 
Betriebssysteme verwenden beispielsweise Task-Scheduler zum 
Verwalten mehrere Aufgaben (Tasks), uin ein Multitasking, zur. 
Verfugung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestimmten Zeitpunkt ah, 
starten andere Tasks und kehren nach deren Abarbeitung zur 
Weiterbearbeitung des abgebrochenen Tasks zuriick. 
Sofern sichergestellt ist, dafi eine Konf iguration - die der 
Abarbeitung eines Tasks entspricht - nur nach der kompletten 
Abarbeitung - d.h. wenn alle innerhalb dieses Konf igurat ions - 
zyklusses zu bearbeitende Daten und Zust^nde gespeichert sind 
- terminiert, kdnnen lokal relevant e ZustSnde ungespeichert 
bleiben . 

Sofern der Task-Scheduler allerdings Konf igurationen vor deren 
vollstandiger Abarbeitung abbricht, mtissen lokale/ZustSnde . 
und/oder Daten gespeichert werden. Weiterhin ist dies von Vor- 
teil, wenn die Abarbeitungszeit einer Konfiguration nicht vor- 
hergesagt werden kann. In Verbindung mit dem bekannten Halte- 
problem und dem Risiko, dafi eine Konfiguration (z.B. durch ei- 
nen Fehler) gar nicht termini^rt, erschelnt dies weiterhin 
sinnvoll, um damit einen Deadlock des gesamten Systems zu ver- 
hindern . 

Mit anderen Worten sind, unter BerUcksichtung von Taskwech- 
seln, relevante Zustande auch als solche anzusehen, die far 
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einen Taskwechsel und ein erneutes korrekes Aufsetzen der Da- 
tenverarbeitung nbtwendig sind. 

Bei einem Taskswitch ist sbmit der Speicher fiir Ergebnisse urid 
ggf . auch der Speicher ftir die Operanden zu sichern und zu ei- 
nem spSteren Zeitpunkt, also bei der Rackkehr zu dieseni Task; 
wieder herziistellen.. Dies kann vergleichbar zu den PUSH/ POP 
Befehlen und Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitung zu sichern, 
also der Zeiger auf die zuletzt vollstSndig bearbeiteten Ope- 
randen. Es sei hier besonders auf PACT18 verwiesen. 

Abhangig von der Optimierung des Taskswitches gibt es bei- 
spielsweise zwei Mdglichkeiten: 

a) Die abgebrochene Konf iguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt von neuem, als ob die Bearbeutung der Kbnfiguration rioch 
gar nicht begonnen wurde. Mit anderen Worten werden einfach 
alle Datenberechnungen von vorne an ausgeftlhrt, wobei ggf. Be- 
rechnungen bereits zuvor durchgefUhrt wurden. Diese M5glich- 
keit ist einfach aber nicht sehr effizient. 

b) Die abgebrochene Konfiguxation wird neu konfiguriert, wobei 
die Operaden und bereits berechneten Ergebnisse in die jewei- 
ligen Speicher geladen werden. Die Datenverarbeitung wird bei 
den Operanden fortgesetzt die nicht mehr vollstandig berechnet 
wurden. Dieses Verfahren ist sehr viel effizienter, setzt aber 
voraus, dafi ggf. zus^tzliche Zustande die wahrend der Verar- 
beitung der Konfiguration entstehen relevant werden, bei- 
spielsweise muB zuinindest ein Zeiger auf die zuletzt vollstSn- 
dig verechneten Operanden gesichert werden, damit bei deren 
Nachfolgern nach erfolgter neuer Konfiguration neu aufgesetzt 
werden kann. 

Eine besonders bevorzugte Variante zur Verwaltung von relevan- 

ten Daten wird durch den nachfolgend beschriebenen Kontext 

Switch zur Verfugung gestellt. Bei Task-Wechseln und/oder bei 
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der Ausfiihrung von Konfigurationen und derem Wechsel (siehe 
beispielsweise Patentanmelduhg PACTIS, die zu Offeribarungs- 
zwecken vollumfanglich eihgegliedert ist) kann es erfbrderlich 
sein, Daten Oder Zustande, die typischerweise nicht zusammen 
mit den Arbeitsdaten in die Speicher abgelegt werden/ da sie 
beispielswei3e lediglich einen Endwert markiieren, faf eine ^ 
nachfolgende Konf iguration zusichern. 

Der erfindungsgemaBe Kontext Switch wird derart durchgefUhrt, 
dass eine.erste Konf iguration entfernt wird^ die zu sichernden 
Daten verbleiben in den entsprechenden Speichern (REG) (Spei- . 
Cher, Register, zahler, etc) . 

Eine zweite Konf iguration wird geladeh, diese verbindet die 
REG in geeigneter Weise und definierter Reihenfolge mit einem 
Oder mehreren globalen Speicher(n). 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die globalen Speicher zuzugreifen. 
Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen ftir den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
entfernten ersten Konfiguration eindeutig zugeordnet werden 
k5nnen. 

Mit anderen Worten, es sind bevorzugt far unterschiedliche 
Konfigurationen unterschiedliche Adressenr^ume vorgesehen. Die 
Konfiguration entspricht einem POSH gew5hnlicher Prozessoren. 

Danach verwenden andere Konfigurationen die Ressourcen. 

Die erste Konfiguration soil wieder gestartet werden. Zuvor 

wird eine dritte Konfiguration gestartet, die die REG der er- 
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sten Konfiguration in einer definierten Reihenfolge miteinan- 
der verbindet. 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die giobaien Speicher zuzugreifen. 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 

Ein Adressgenerator generiert Adressen derart, dass ein kor^ 
rekter Zugrif f auf die der ersten Konfiguration zugeordnete 
PUSHAREA erfolgt. Die generierten Adressen und die konfigu- 
rierte Reihenfolge der REG sind derart, dass die Daten der REG 
in der ursprunglichen Ordnung aus den Speichern in die REG ge- 
schrieben werden. Die Konfiguration entspricht einem POP ge- 
w5hnlicher Prozessoren, 

Die erste Konfiguration wird wieder gestartet. 

ZusammengefaBt wird ein Kontext Switch derart durchgefahrt, 
dass durch das Laden besonderer Konf igurationen, die ahnlich 
von PUSH/POP bekannter Prozessorarchitekturen arbeiten, die zu 
sichernden Daten mit einem giobaien Speicher ausgetauschen 
werden. 

Die Funktion soil in einem Beispiel verdeutlicht werden: 

Eine Funktion addiert 2 Zahlenreihen^ die LSnge der Reihen ist 

zur Obersetzungszeit nicht bekannt, sondern erst zur Laufzeit. 

proc example 

while Klength do 
xti] - a[i] + b[i] 

Die Funktion wird nun wahrend ihrer Ausfuhrung unterbrochen^ 
beispielsweise durch einen Task-Switch oder weil der far x 

37 



wo 02/103532 



PCT/EP02/06865 



vorgesehene Speicher voll ist. a,b,x befinden sich zu diesem 
Zeitpunkt erf indungsgemSB in Speichern. i und ggf . length mUs- 
sen jedoch gesichert werden. 

Dazu wird die Konfiguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konfiguration push ge- 
startet, die i und length aus den Registern liest und in einen 
Speicher schreibt* 

proc push 

mem[<push_adr_example>] = i 
push_adr_example++ 
mera[<push_adr_example>] = length 

Nach der AusfQhrung wird push terminiert und die Registerin- 
halte konnen geloscht werden. 

Andere Konf igurationen werden ausgefUhrt. Nach einiger Zeit 
wird die Konfiguration example wieder gestartet. 
Zuvor wird eine Konfiguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest. 

proc pop 

i « mem[<push_adr_exan^le>l 

push_adr_example++ 

length « mein[<push^adr_exaniple>] 

Nach der Ausfiihrung wird pop terminiert und die Registerinhal- 
te bleiben bestehen. Die Konfiguration example wird wieder ge- 
startet 

Beschreibung der Figuren 

Figur 1 verdeutlicht ein Beispiel das vorgeschlagene Verfahren 
und zeigt einen mdglichen Systemaufbau. Dabei ist ein PROZES- 
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SOR (0101) uber eln geeignetes Interface (0102) zum Daten- und 
Status -austausch mit einer VPU (0103) verbunden. * 
Ein PROGRAMM-Code (0110) wird (z. B. durch eihen Praprozessor 
£{Sir elnen Compiier) beisplelsweise gemafi den beschriebenen Ex- 
traktionsmethoden in einen fidr den PROZESSOR geeigneteh Teil 
ioill) xind eihfen VPU-geeigheten T^^ (0112) zerlisgt. 

Dili wird durch einen dem PROGRAMM-Code entsprechenden Stan- 
dard Compiler (0113) ubersetzt, wobei zuvor der zusatzliche 
Code 2ur Beschreibung und Verwalturig des Interfaces (0102) 
zwischen dem PROZESSOR und einer VPU aus einer Datenbank 
(0114) eingefugt wird. Auf 0101 ausfuhrbarer sequentieller . 
Code wird generiert (0116) imd sofern notwendig die entspre- 
chende Programmierung (0117) des. Interfaces (0102) . 
Der Standard-Compiler kann dergestalt sein, daS er als 
marktiibliches Werkzeug oder im Rahmen einer marktObllchen Ent- 
wicklungsumgebung vorliegt. Der Praprozessor und/oder m&gli- 
cherweise der VPU-Compiler und/oder moglicherweise der Debug- 
ger iind weitere Werkzeuge kdnnen beispielsweise in eine beste- 
hende marktubliche Entwicklungsumgebung integrlert werden. 

0112 wird durch einen VPU Compiler (0115) ubersetzt^ wobei zu- 
satzlicher Code zur Beschreibung und Verwaltung des Interfaces 
(0102) aus einer Datenbank (0114) eingefugt wird. Auf 0103 
ausfuhrbare Konf igurationen werden generiert (0118) und sofern 
notwendig die entsprechende Programmierung (0119) des Interfa- 
ces (0102) . Es soil ausdrflcklich erwahnt werden, dafi prinzipi- 
ell auch Compiler nach DE 101 39 170.6 f\lr 0115 verwendet wer- 
den kdnnen- 

In Figur 2 ist beispielhaft ein prinzipieller Ablauf einer 
Compilation dargestellt. Ein PROGRAMM (0201) wird in der Ex- 
traktionseinheit (0202) nach unterschiedlichen Verfahren in 
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VPU-Code(G203) und PROZESSOR-Code (0204) zerlegt. Unterschied- 
liche Methoden icdnnen in- beliebiger Kombination zur Extraktlon 
angewendet werden, beispielsweise Hinweise im ursprunglichen 
PROGRAMM (0205) und/oder Unterprogrammauf rufe (0206) und/oder 
Analyseverfahreri (0207) und/oder eine Verwertung von objekt- 
orientierten Klassenbibliotheken (0206a) , Der jeweils extra- 
hierte Code wird ggf . ilbersetzt und ggf • auf seine Eignung fur 
das jeweilige Zielsystem hin liberpruft (0208) . Dabei ist eine 
Riickkopplung (0209) auf die Extraktlon m5glich, urn Verbesse* 
rungen durch eine geanderte Zuordntuig der Codes zu einem PRO- 
ZESSOR Oder einer VPU bzw. einer Vielzahl derselben zu erhal- 
ten\ 

Danach (0211) wird 0203 durch den Interface -Code aus einer Da- 
tenbank (0210) erweitert (0212) und/oder 0204 wird durch den 
Interface -Code aus 0210 zu 0213 erweitert. 
Der entstandene Code wird auf seine Performance analysiert 
(0214), ggf. ist eine Riickkopplung (0215) auf die Extrsiktion 
moglich, um Verbesserungen durch eine geanderte Zuordnung der 
Codes zum PR02ESS0R oder einer VPU zu erhalten, 
Der entstandene VPU-Code (0216) wird fdr eine weitere Uberset- 
zung an einen nachgeschalteten fur die VPU geeigneten Compiler 
weitergegeben. Der entstandene PROZESSOR-Code (0217) wird fClr 
die weitere Ubersetzung in einem beliebigen nachgeschalteten 
fdr den PROZESSOR geeigneten Compiler weiterverarbeitet . 

Es soil angemerkt werden, daS' einzelne Schritte je nach Ver- 
fahren ausgelassen werden k&nnen. Wesentlich ist, daS ein zu- 
mindest weitgehend kon5>letter und ohne, wenigstens ohne signi- 
fikanten Eingriff durch den Programmierer direkt ubersetzbarer 
Code an jeweils nachgeschaltete Compilersysterae ausgegeben 
wird. 
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Es wird denoiach vorgeschlagen, daJS ein Praprozessormittel mit 
elnem Codeeingaing fur diiB ElnsjpeiisvLhg von zii cbn^ilierendem 
Code, mit Cbdeanalysemitteln, insbesondere Codestruktur 
und/oder Datenformat- uiid/oder Datenstroms-Erkennungs- 
uiid/oder Bewertungsmittelri sowie mit eirietn Aufteilungsbewer^ 
tuhgsmittel 2ur BeWeirtuhg einer ini Anspfechen auf Signale aus 
dem Codeanalysemittel vorgenommenen Codeauf teilung isowie gege- 
benenfalls elnem Iterationsmittel zur Wiederholimg einer Code- 
auf teilung bis zum Erreichen stabiler und/oder hinreichend ak- 
zeptctbler Werte niit zumindest zwei Teilcbdeausgangen verseheh 
iet, wobei ein erster Teilcodeausgang Teilcode fiir zti^iindest 
einen herkSmmlichen Prozessor ausgibt, und wenigstens ein wei- 
terer Teilcodeausgang zur Abarbeitung mit rekonf igurierbaren 
Logikeinheiten, insbesondere mehr- bzw. mult idimensionale ins- 
besondere Zellstrukturen aufweisend, insbesondere grobgranula- 
re datenverarbeitende \ind/oder Logikzellen (PAEs) mit Rechen- 
werken und dergleichen sowie ggf . zugeordneten Registermitteln 
imd/oder feingranularen Steuer- xind/oder Kontrollmitteln wie 
Zustandsmaschinen, RDY/ACK- Trigger- und Kommunikationsleitxin- 
gen usw bestimmten Code ausgibt. Beide Teilcodeausgange konnen 
in multiplexweise seriell auf einem physikalisctien Ausgang 
liegen. 

Die Datenbahk fur die Interface- Codes (0210) wird unabhangig 
und vor dem Compilerdurchlauf aufgebaut. Beispielsweise sind 
folgende Quellen fiir die Datenbank m5gli'ch: Vom Lieferanten 
vorgegeben (0220), vom Benutzer programmiert (0221) oder auto- 
matisch von einem Entwicklungssystem generiert (0222) . 

Der Aufbau einer besonders bevorzugten VPU ist in Figur 3 dar- 
gestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0301) steuern und verwalten eine Anordn\ing von rekon- 
f igurierbaren Elementen (PACs) (0302). Den CT's ist ein. loka- 
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ler Speicher fdr die Konf igurationen zugeordnet (0303) . Der 
Speicher veirf iigt weiterhin fiber ein interface (0304) zu eineni 
globalen iSpeicher, der die Konf igurationsdaten zur Verfugung 
stellt. Uber ein Interface (0305) sind die Konfigurationsab- 
ISuft steuerbar. Bin Interface det rekonf igurierbaren Elemente 
(0302) zur Ablauf steuerung und Ereignisverwaltung (0306) ist 
vorhanden, ebenso ein Interface zum Datenaustausch (0307) . 

Pigur 4 zeigt einen Ausschnitt aus einem beispielhaf ten CPU 
System, beispielsweise einem DSP des Types C6000 von Texas In- 
struments (0401) . Dargestellt sind Programmspeicher (0402) , 
Datenspeicher (0403 V> beliebige Peripherie (0404) und EMIF 
(0405) . 6ber einen Speicherbus (0406) und einem Peripheriebus 
(0407) ist eine VPU als Coprozessor integriert (0408) . Ein 
DMA-Kpntroller (EDMA) (0409) kann beliebige DMA-Transfers, 
beispielsweise zwischen Speicher (04Q3) und VPU (0408) oder 
Speicher (0403) und Peripherie (0404) durchffihren. 

Figur 5 zeigt eine abstraktere Systemdef inition, Einer CPU 
(0501) ist Speicher (0502) zugeordnet auf den diese schreiben- 
den und/oder lesenden Zugriff besitzt, Eine VPU (0503) ist mit 
dem Speicher gekoppelt. DijB VPU ist in einen CT-Teil (0509) 
und die rekonf igurierbaren Elemente zur Datenverarbeitung 
(0510) xintergliedert . 

Zur Steigerung der Speicherzugrif f e kann der Speicher mehrere 
unabh&ngige Zugriff sbusse aufweisen (multiport) . In einer be- 
sonders bevorzugten Ausgestaltung ist der Speicher in mehrere 
unabhangige Segmente (Speicherbanks) segmentiert, wobei auf 
jede Bank unabhangig zugriffen werden kann. Samtliche Segmente 
liegen vorzugsweise innerhalb eines einheitlichen Adressraums. 
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Vorzugsweise steht ein Segment hauptsachlich fiir die CPU zur 
Verfiigung (0504), ein weiteres Segment steht hauptsachlich fir 
die Datenverarbeitting der VPU zur VerfClgung (0505), ein weite- 
res Segment steht hauptsachlich fflr die Konf igurationsdaten 
der VPU zur Verfugung (0506). 

Typischerweise und bevorzugt weist eine vollausgestailtete VPU 
eigene Adressgeneratoren \ind/oder DMAs auf urn Datentransfers 
durchzuf xihren . Alternativ tind/oder zusatzlich ist es moglich, 
dass ein DMA (0507) innerhalb des Systems (Fig. 5) f{ir Daten- 
transfers mit der VPU vorgesehen ist. 

Das System enthSlt 10 (0508) auf die CPU und VPU Zugrif f haben 
konnen. 

Sowohl CPU als auch VPU kdnnen jeweils dedizierte Speicherbe- 
reiche und lO-Bereiche aufweis.en, auf die der jeweils andere 
keinen Zugrif f hat. 

Bin Datensatz (0511) der im Speicherbereich und/oder im 10- 
Bereich und/oder partiell in einem von beiden liegen kann wird 
zur Koraraunikation zwischen CPU und VPU verwendet, z.B. zum 
Austausch von Basisparametern und Steuerinforiaation. Der Da- 
tensatz kann beispielisweise fplgende Information beeinhalten: 

1. Basisadresse (n) des CT-Speicherbereiches in 0506 zur Lo- 
kalisierung der Konf igurationen*. 

2 • Basisadresse (n) von Datentrcuisfers mit 0505. 

3. 10 Adressen von Datentrauisfers mit 0508. 

4. Synchronisationsinformation, z.B. Zurxicksetzen, anhalten, 
start en der VPU. 

5. Statusinformation der VPU, z.B. Fehler oder Zustand der 
Datenverarbei timg . 
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Die Synchronisation der CPU und VPU erfolgt durch Polling von 
Daten und/oder bevorzugt: durch ihterruptsteuenrng (0512) 1 

Figur 6 zeigt eine mogliche Ausgestaltung der Interf acestruk- 
tur einer VPU zur Einbindiing in ein isystem Shnlich Figixr 5. 
Dazu werden der VPU ein Speicheir/DMA- und/oder lO- Interface 
zum Datentransfer zugeordnet (0601), ein weiteres System- 
Interface (0602) abernimmt die Ablauf steuerung wie z.B. das 
Verwalten von Interrupts, das Starten/Stoppen, der Verarbei- 
tung, Austausch von Fehlerzustanden, etc. . 
Das Speicher/DMA- und/oder ID- Interface wird an einen Spei- 
cherbus und/oder lO-Bus .auigeschlossen. 

Das System- Interface wird vorzugsweise an einen lO-Bus ange- 
schlossen, kann jedoch altemativ oder zusStzlich entsprechend 
0511 auch an einen Speicher angeschlossen sein. 

Die Interfaces (0601, 0402) konnen zur Anpassung von xinter- 
schiedlichen Arbeitsf requenzen von CPU und/oder VPU und/oder 
System ausgestaltet sein, beispielsweise kann das System bzw. 
die CPU mit zB derzeit 500MHz und die VPU rait 200MHz arbeiten. 

pie Interfaces kSnnen e|ine, tJbersetzung der Busprotokplle 
durchfiihren, beispielsweise kann das VPU interne .Prptokoll auf 
ein extemes AMBA-Busprotokoll umgesetzt werden. Sie bewirken 
also Busprotokolliibersetzungsmittel und/oder sind fiir die Bus- 
protokolliibersetzung ausgebildet, insbesondere die Busproto- 
kolliibersetzung zwischen intemem VPU-Protokoll und bekanntem 
Busprotokoll . Es ist auch moglich, eine Konvertierung direkt 
auf CPU- interne Busprotokolle vorzusehen. 

Das Speicher/DMA- und/oder ID-Interface unterstutzt den Spei- 

cherzugriff der CT auf einen externen Speicher, der vorzugs- 
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weise direkt (memory mapped) erfolgt. Der Datentransfer der 
CT(s) und/oder PAC(s) kann gepuffert z.B. iiber FIFO-Stufen er- 
folgen. Extemer Speicher kann direkt angesprochen und adres- 
siert werden, weiterhin kSnnen DMA interne und/oder externe 
DMA-Transfers durchgefuhrt werden. 

Uber das System- Interface erfolgt die Steuemhg der Datienver- 
arbeitung, wie beispielsweise die Initialisierung \ind/oder der 
Start von Konf igurationen. Des weitisren werden Statue und/oder 
Fehlerzustande ausgetauscht . Interrupts fur die Steuerung und 
Synchronisation zwischen den CT's und einer CPU konnen xinter- 
stiitzt werden. 

Das System- interface kann VPU- interne Protokolle derart kon- 
vertieren, dass diese auf externe (Standard) -Protokolle umge- 
setzt werden (z.B. T^MBA) . 

Ein bevorzugtes Verfahren zur Codegenerierung fur das be- 
schriebene System ist in anderen Teilen dieser Anmeldung be- 
schrieben. Das Verfahren beschreibt einen Compiler, der Pro- 
grammcode in Code fiir eine CPU und Code fur eine VPU zerteilt. 
Nach unterschiedlichen Verfcdiren wird die Zerlegung auf die 
xinterschiedlichen Prozessoren durchgefuhrt* In einer besonders 
beyorzugten Ausfuhruhg; werden dabei die jeweiligen zerlegten 
Codes urn die Interface-Routinen zur Kommunikation zwischen. CPU 
und VPU eirweitert. Die Erweiterung ksuin automatisch durch den 
Compiler erfolgen. 

Die hachfolgende Tabellen zeigen beispielhaf te Kommunikationen 

zwischen einer CPU und einer VPU. Den Spalten sind die jewei- 

lig aktiven Funktionseinheiten zugeordnet: CPU, System-DMA .und 

DMA-Interface (EDMA) bzw. Speicher- Interface (Speicher- I/P) , 

System- Interface (System- I/F, 0602), CT's, sowie die PAG. In 

den Zeilen sind die einzelnen Zyklen in ihrer Ausfuhrungsrei- 
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henfolge eingetragen. Kl referenziert eine auszufOhrende Kon- 
figuration 1. 



pie erste Tabelle zeigt beispielsweise einen Ablauf bei Ver- 
weiidxing der System-DMA (EDMA) zum Datentrahsfer: 
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Es ist zu earwahnen, dass die Synchronisation zwischen der EDMA 
und der VPU automatisch fiber das Interface 0401 erfolgt, d.h. 
DMA-Tranfers finden nur statt, wenn die VPU dafur bereit ist. 



In einer zweiten Tabelle ist beispielsweise ein bervorzugter 
optimierter Ablauf dargestellt. Die VPU besitzt selbst direk- 
ten Zugrif f auf den Konf igurationsspeicher (0306) . Desweiteren 
werden die Datentransfers durch DMA-Schaltung innerhalb der 
VPU ausgefflhrt, die beispielsw-ise fest implementiert sein 
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konnen iind/oder durch die Konf iguration von konf igurierbaren 
Teilen der PAC entstehein. 
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Der Aufwamd fur die CPU ist minimal - 

Zusammenfassiend befaSt sich die vorliegende Erf indung: itiit Ver- 
fahren, die eine tlbersetziing einer klassischen Hochsprache wie 
Pascal, C, C++, Java, etc. auf eine rekonf igurierbare Archi- 
tektur ermSgJicht. Das Verfahren ist derart ausgelegt, daS nur 
die jeweils fur die rekonf igurierbare Zielarchitektur geeigne- 
ten Teile des zu Obersetzenden Programmes extrahiert werden. 
Die verbleibenden Teile des Programmes werden auf eine konven- 
tionelle Prozessorarchi tektur ubersetzt. 

In Figur 7 sind aus Grunden der Obersichtlichkeit nur die re- 

levanten Komponenten (i.b. der CPU) aufgezeigt sind, wobei ty- 
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pisch eine wesentliche Zahl weiterer Komponenten und Netzwerke 
vorhanden sein wird. 



Eine bevorzugte Implement lenihg wie beispielsweise in Pigur 1 
dargestellt kauin unterschiedlichie Datentraiisfers zwi^chen ei- 
ner CPU (0701) urid VPU (0702) vorsehen. Die auf der VPU auszu- 
fiihrenden Konf igurationen werden durch den Instniktionsdekoder 
(0705) der CPU selektiert, der bestimmte fttr die VPU bestimmte 
Instruktionen erkennt und die CT (0706) derart ansteuert, dass 
diese die entsprechenden Kohfigurationen aus einem der CT zu- 
geordneten Speicher (0707) - der insbesondere mit der CPU ges- 
hared werden oder derselbe wie der Arbeit sspeicher der CPU. 
sein kann, in das Array aus PAEs (PA, 0108) ladt. 

Es sind CPU-Register (0703) vorgesehen, um bei einer Register- 
koppl\ing Daten zu entnehmen, zu verarbeiten und in ein CPU- 
Register zuruckschreiben. b Fflr die Datensynchronisation ist 
ein Statusregister (0704) vorgesehen. Weiter ist ein Cache 
vorgesehen, der dafflr vorgesehren ist, daS wenn Daten ausge- 
tauscht werden sollen, die Jcurz zuvor von der CPU verarbeitet 
warden, diese voraussichtlich noch im Cache (0709) der CPU 
liegen bzw. spfort anschliessend von der CPU verarbeitet wer- 
den. 

Der exteme Bus ist mit (0710) bezeichnet und es werden dar- 
\iber zB aus einer damit verb\indenen Datenquelle (z.B. Spei- 
cher, Peripherie) gelesen, bzw. an den extemen Bus und der 
damit verbundenen Datensenke (z.B. Speicher, Peripherie) ge- 
schrieben. Dieser Bus kann insbesondere derselbe wie der ex- 
teme Bus der CPU sein (0712 & gestrichelt) . 

Ein Protokoll (0711) zwischen Cache und Bus ist implementiert, 
das fur einen korrekten Inhalt des Caches sorgt. Mit (0713) 
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ist ein FPGA (0713) bezeichent, der rait der VPU gekoppelt sein 
kanh, urn feingranulare Datenverarbeitung zu ermoglichen 
xHid/oder ein flexible adaptierbare Interface (0714) (z.B. di- 
verse serielle Schnittsteilen (V24/ USB, etc.); diverse pairal- 
leie Schnittsteilen, Festpiattehschnittsteileh, Ethernet, te- 
lekdmmunikationsschnittstelleri (a/b, TQ, ISDN, DSL,., etc).) zu 
weiteren Baugruppen \and/oder dem extemen Bussystem (0712) zu 
ermoglichen. 

Ehtsprechend Pigur 8 bef indet sich Speicherbereich des Be- 
triebssystems eine Tabelle Oder verkettete Liste (LINKLIST, 
0801) , die auf samtliche VPUCALL-Tabellen (080.2) in der Re i- 
henfolge ihrer Erstellung zeigt. 
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Patentanspr{!lche 

1. Verfahren zur Obersetzxing von Progratranen auf ein System be- 
steherid aus wenigsftens einem ersten Prpzessor imd einer re- 
korif igurierbaren Einheit, dadurch gekennzeichnet , dafi die 
Codeteile, die fir die rekdnfigrurierbafe Einheit geeignet 
sind, bestimmt urid extrahiert und/oder separiert wird, wo- 
bei verbleibender Code zur Abarbeitimg durch den ersten 
Prozessor bestimmt wird. 

2. Verfahren nach Anspnich 1, dadurch gekennzeichnet, dafi dem 
fur den Prozessor extrahierten Code Interface-Code zugefiigt 
wird, der eine Kommunikation zwischen Prozessor und rekon- 
f igurierbarer Einheit entsprechend des Systemes ermoglicht. 
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3. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet/ daS dem fur die rekonfigurierbarer Einheit 
extrahierten Code solcher Interface -Code zugefflgt wird^ 4er 
eine koniinimikation zWischen Prozessor und rekonfigurierba- 
rer Einheit entsprechend des Systems ermogiicht, 

4. Verfahren nach einem der vorhergehenden AnsprQche, dadurch 
gekennzeichnet, da& der zu extrahierende Code aufgrund von 
automatisierten Analysen festgelegt wird. 

5. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS Hinweise im Code zur Peststellung des 
zu extrahierehden Code automatisch ausgewertet werden. 

Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS der zu extrahierende Code aufgrund von 
Aufrufen von Unterprograramen festgestellt wird* 

7. Verfahren nach einem der vorhergehenden AnsprClche, dadurch 
gekennzeichnet, dafi ein Interface-Code vorgesehen wird, 
der eine Speicherkppplung (Shared-Mempry) yorsieht 
und/oder eine Registerkopplung iind/pder eine Kopplung mit- 

. tels* eines- Netzwerkes b^ewirkt • 

8. Verfahren nach einem der vorhergehenden AnsprCiche, dadurch 

gekennzeichnet, daS der extrahierte Code und/oder mit einer 
gegebenen Extraktion erzielbaren Resultate analysiert wird 
und gegebenenfalls die Extraktion mit neuen verbesserten 
Parametem emeut gestartet wird. 

9. Verfahren nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, daS dem extrcdiierten Code Steuer-Code zur 
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Verwaltung und/oder Steuerung und/oder Kommunilcation der 
Entwicklungssysteme zugef igt wird . 

10. Verfahren nach einem der vorhergehenden AnsprGche, worin 
der erste Prozessor eine kbiiventibnelle Prozessorarchitek- 
tur aufweist, insbesoiidere ein Prozessor mit vori - Neumann 
- und/oder Harwardarchitektur, Kontroller, CISC-, RISC-, 
VLIW-, DSP-Prozessor. 

11. Verfahren insbesondere nach einem der vorhergehenden An^ 
spriiche zur Ubersetzung von Programmen auf ein System be- 
stehend aus einem Prozessor und einer rekonf igurierbaren 
Einheit, dadurch gekennzeichnet, dafi die Codeteile, die f\ir 
die rekonfigurierbare Einheit geeignet sind, extrahiert 
werden, der verbleibende Code derart extrahiert wird, daS 
er mittels eines beliebigen gewohnlichen unmodif izierten 
far den Prozessor geeigneten Compilers Obersetzbar ist. 

12. Vorrichtung zur Datenverarbeitung mit wenigstens einem 
herkSmmlichen Prozessor und wenigstens einer rekonf igu- 
rierbaren Einheit, dadurch gekennzeiclmet, daS ein Mittel 
zum Informationsaustausch, insbesondere von Daten- und 

. Statusinformat ion, zwischen-herkdmmlichem Prozessor und 
rekonf igurierbarer Einheit aufweist, wobei das Mittel so 
ausgebild^t ist, daS ein Daten- und Status information zwi- 
schen denselben wShrend der Abarbeitung eines oder mehrere 
Programme mdglich ist xxnd/qder ohne daS insbesondere die 
Datenverarbeitxing auf dera rekonf igurierbaren Prozessor 
und/oder dera herkdmmlichen Prozessor signifikant unterbro- 
chen werden mx&. 
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